DP83800 Software 
Programmers Guide 

The DP83800 Software Programmers Guide is designed to 
aid in the development of software for the DP83800 10/100 
ISA based network adapter. It is recommended that the 
DP83800 datasheet be read and understood before reading 
this document. 
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1.0 INTRODUCTION TO THE DP83800 

The DP83800 is designed specifically for ISA bus adapter 
applications. Its design is optimized for high throughput, low 
CPU utilization and low cost. 

It implements a simple FIFO-based slave I/O interface to 
the ISA bus to simplify the task of writing network device 
drivers. Additionally, the DP83800 contains many features 
that are aimed specifically at increasing overall performance 
in the most popular network environments. 

1.1 10/100 Mb/s Operation 

The DP83800 is capable of operating as a 10 Mb/s stan- 
dard Ethernet® controller or as a 100 Mb/s Fast Ethernet 
controller. When coupled with National Semiconductor's 
DP83840 10/100 Mb/s physical layer, mode configuration 
is automatic. The DP83800 provides an interface to the 
DP83840 through the Media Independent Interface (Mil). 
Through the MM, software can set the physical layer to auto 
negotiate or it can force any physical layer configuration 
mode desired. 

1.2 Buffer Architecture 

The DP83800 provides an easy to use buffer architecture. 
As packets are received, they are stored sequentially in the 
5 kbyte receive FIFO. The status and receive byte count are 
also stored in a separate FIFOs. The driver need only per- 
form a series of reads from a particular register to move the 
packet from the FIFO into system memory. Similarly, the 
driver need only perform a series of writes to the same reg- 
ister in order to transmit a packet. This simplified buffer ar- 
chitecture enables the driver to implement streamlined data 
transfer routines. 

1.3 Resource Configuration 

The DP83800 conforms to the Plug and Play 1 .0a specifica- 
tion for auto-configuration of Plug and Play ISA devices. Be- 
cause of this, the DP83800 will be automatically configured 
when placed in any system which supports Plug and Play 
isolation and configuration management routines. In these 
systems, the drivers need only query the resident configura- 
tion manager to obtain all necessary configuration informa- 
tion such as base I/O address and IRQ. 
The DP83800 also supports a "legacy" mode of operation 
where it behaves like traditional ISA adapters and powers 
up with pre-assigned resources. These resources are stored 
in the EEPROM devices on the board and are loaded into 
the DP83800 on power up. In this mode, the driver can ob- 
tain configuration information in several different ways as 
described below. 



D 
■D 

00 
W 
09 
O 
O 

if) 

o 

fi> 

(D 
■D 
O 

fi) 

3 
3 

(D 
(ft 

a 

c 
E 

(D 



Ethernet® is a registered trademark of Xerox Corporastion. 



<0 

Ol 



© 1 995 National Semiconductor Corporation TL/F/ 1 2460 



RRD-B30M105/Printed in U. S. A. 



The driver can obtain the base I/O location using methods 
inherent in the specific driver specification being written to 
(such as NET.CFG files for ODI and PROTOCOL.INI files for 
NDIS drivers) and then read some of the DP83800 configu- 
ration registers to obtain the other resources. 
The driver can also perform its own Plug and Play isolation 
to locate the DP83800 adapter. Once isolated, the driver 
can read the resource information from special Plug and 
Play registers. This allows the driver to locate the adapter in 
traditional ISA systems without having to perform danger- 
ous searches of I/O space and without requiring configura- 
tion files. 

And lastly, the DP83800 supports EISA configuration regis- 
ters when used in an EISA system. In these systems, re- 
sources are assigned by the EISA BIOS at boot time and 
programmed into the IO/IRQ configuration register and the 
boot PROM configuration register. 

In all modes, the DP83800 will respond to Plug and Play 
isolation sequences. This is the standard method of chang- 
ing adapter configuration. 

Supporting these three modes of configuration allows the 
DP83800 to be easily configured and accessed in today's 
environments as well as future ones. 

1.4 Registers 

1.4.1 Run-Time Registers 

The DP83800 contains over 45 run-time registers used to 
operate the device. Because the ISA platform has limited 
I/O space, the DP83800 uses paged registers in order to fit 
these 16-bit registers in 32 bytes of ISA I/O space. To re- 
duce the need to continually switch register pages, the 
DP83800 has registers arranged on one "fixed page", as 
well as 5 "variable pages". The fixed page is always present 
in the first 16 I/O locations of the base address. The second 
16 I/O locations hold the variable page registers. Which of 
the variable pages is present is indicated in the master 
Command Register (CR, fixed page, offset OOh). The group- 
ing is arranged so that after initial driver configuration, the 
driver can leave page 1 the active variable page and have 
little or no need to change to another. 
Please refer to the DP83800 datasheet for a detailed de- 
scription of each of the registers and its bit significance. 

1.4.2 Plug and Play Registers 

The DP83800 has a set of Plug and Play registers used for 
configuration of the device. They are available only through 
the Plug and Play interface after the adapter has been iso- 
lated. 



The DP83800 has all of the standard Plug and Play registers 
used for isolation and resource allocation. It also has a 
mode configuration register used to alter the power-up ac- 
tions of the DP83800. Please refer to the DP83800 data- 
sheet for a detailed description of all Plug and Play regis- 
ters. 

1.4.3 EISA Configuration Registers 

The DP83800 has a set of registers which can be used in an 
EISA system. These registers allow for detection of the 
adapter as well as configuration. 

The configuration registers are slot specific when placed in 
an EISA machine. For example, if the DP83800 is placed in 
slot 3 of the host machine, the EISA Product ID would begin 
at 3C80h. Please refer to the DP83800 datasheet for a de- 
tailed description of all EISA registers. 

1.5 Node Management 

1.5.1 Management Information Base (MIB) 
Statistics Counters 

The DP83800 contains an extensive block of statistics 
counters that are automatically updated as each event oc- 
curs. The counters provide a set of statistics compliant with 
the following management specifications: MIB II, Ether-like 
MIB and IEEE MIB. 

With these counters, it is easy for drivers to keep accurate 
statistics without needing to count them on a per-packet 
basis. This allows for faster transmit and receive routines 
and greater overall driver performance. 

1.5.2 MIB Interlace 

To access the MIB statistics counters, the DP83800 pro- 
vides a register interface to the MIB block. This interface 
consists of the MIB Control Register (MCR, variable page 3, 
offset 14h) and the MIB Data Registers (MDRO and MDR1, 
variable page 3, offsets 10h and 12h). 
The MCR allows the software to choose which set of statis- 
tics to enable (see datasheet) as well as clear, test and 
access all the counters. In order to access the MIB coun- 
ters, the software need only set the Access Pointer Reset 
bit (bit 9) to reset the access pointers and then set the off- 
set in bits 5-0 to begin reading the counters. The software 
then reads from the MDR registers to retrieve the informa- 
tion. 

The two MDR registers provide a 32-bit interface to the MIB 
counters. If the software performs 32-bit input instructions 
to read the data, the CPU will read both MDRO and MDR1 
consecutively to get the full 32-bit value for each statistic. 
The software may continue to read from the MDR registers 
until all statistics have been gathered. 



1.6 EEPROM Interface 

The DP83800 provides an interface to directly access the 
NM93C46 (or compatible) device which holds the Ethernet 
address, Plug and Play information as well as other configu- 
ration data. Specifications for the NM93C46 can be ob- 
tained from the National Semiconductor Corp. Memory Da- 
tabook. 

The interface consists of the EEPROM Control Register 
(EECR, variable page 2, offset 10h) and the EEPROM Data 
Register (EEDR, variable page 2, offset 12h). To read from 
the EEPROM, software must set the EEPROM command 
field in bits 7-0 of the EECR to instruct the EEPROM to 
read from a specified location (see NSC Memory Data- 
book). The software would then poll bit 15, the EEPROM In 
Use bit of the EECR to determine if the read operation is 
completed. When bit 1 5 is cleared, the data is ready to be 
read from the EEDR. 

Write operations are similar to read operations except that 
the write data needs to be placed in the EEDR before set- 
ting bits 7-0 of the EECR to instruct the EEPROM to write 
to a specific location. 

1.7 Media Independent Interface 

The DP83800 provides an interface so that software can 
communicate with the Physical Media Device (PMD) over 
the Media Independent Interface (Mil). Typically the MM is 
used to determine if the current PMD supports a particular 
mode or to configure the PMD to operate in a specific mode. 
The MM consists of the MM Control Register (MICR, variable 
page 2, offset 14h) and the MM Data Register (MIDR, vari- 
able page 2, offset 1 6h). 

To perform a read operation from a register in the PMD, the 
software would write to the MICR a value which contains the 
register address field (bits 4-0), the PMD address field (bits 
9-5) and the access mode set to management read (bits 
11-10 set to 01 respectively). The software would then poll 
bit 15 of the MICR to wait for the operation to complete. 
When the operation is complete, the data is available in the 
MIDR. 

Write operations are similar. Like the EEPROM interface, to 
perform a write operation the data register (MIDR) first 
needs to be programmed with the value to write. Next, the 
software must write to the MICR with the register address 
field, the PMD address field and the value 10 in bits 11-10 
to indicate a management write. When polling of bit 15 of 
the MICR returns 0, the operation is completed. 
Before using the MM, the software should issue a manage- 
ment reset to the MM to synchronize the DP83800 and the 
PMD. This is achieved by writing an 11 to bits 11-10 in the 
MICR. 



1.8 CAM Interface 

The DP83800 provides an interface to the on-board CAM 
used for address matching. Through the interface, the soft- 
ware can read and write to the CAM, mask certain CAM 
entries and determine which CAM entry caused the last 
match. 

1.8.1 CAM Read and Write Accesses 

Before any software CAM accesses, the CAM must be dis- 
abled. To do so, bit 15 of the CAM Control Register (CCR, 
variable page 2, offset 18h) must be cleared. After the ac- 
cess to the CAM is performed, bit 1 5 must be set again to 
resume CAM operation. 

To perform a read from the CAM, the software must first set 
the CAM entry pointer (the CAM has 14 locations, 10 for 
physical/multicast address and 4 for broadcast locations) to 
the desired location, then set bit 6 (the CAM read bit) to 
initiate the read operation. The address in the specified 
CAM location will then be available in the CAM Data Regis- 
ter (CDR, variable page 2, offset 1Ah). For a physical/multi- 
cast address, the full 6 bytes must be retrieved by reading 3 
consecutive words from the CDR. The broadcast CAM en- 
tries are slightly different and require only 2 word reads from 
the CDR (see section in datasheet on CDR for further de- 
tails). 

To perform a CAM write operation, the software needs to 
set the CAM entry pointer, set bit 7 (the CAM write bit) in the 
CCR instead of bit 6 and then write the data to the CDR 
instead of reading from it. This will set the specified CAM 
entry. 

1.8.2 CAM Mask Register 

Once the address data has been written to the CAM, the 
appropriate value in the CAM Mask Register (CMR, variable 
page 2, offset 1Ch) needs to be set in order for the CAM 
logic to use the entry. With the CMR, addresses can be left 
in the CAM and enabled or disabled quickly simply by mask- 
ing it. 

1.8.3 CAM Match Register 

The CAM Mask Register (CMTR, variable page 2, offset 
1 Eh) is used to determine which CAM entry caused the last 
address match. Bits 0-13 in the CMTR correspond to the 14 
CAM entries. If, for instance, bit 1 is set in the CMTR, then 
the address in CAM entry 1 caused the match. 

1.8.4 Other CCR Bits 

Additionally, the CCR contains bits which control other ad- 
dress match criteria. The Accept All Broadcast bit, when 
set, allows all broadcast packets to pass address match. 
The Accept All Multicast does the same for all multicast 
addresses and the Accept All Physical works for physical 
addresses. The CAM need not be disable when setting 
these bits. 



2.0 CONFIGURATION 

The DP83800 supports three modes of configuration: Plug 
and Play mode, legacy ISA mode and EISA mode. The con- 
figuration requirements vary depending on the configuration 
mode selected. 

2.1 Plug and Play Configuration Mode 

Plug and Play configuration mode is generally selected 
when the adapter is to be placed in a system that has a Plug 
and Play BIOS, Plug and Play device drivers or a Plug and 
Play aware operating system. When in such a system, a 
DP83800 configuration program need only ensure that the 
EEPROM location containing the mode configuration byte 
(word 28h, low byte) be set to load only the mode configura- 
tion information. (The I/O, IRQ and boot ROM resources 
are not loaded from the EEPROM.) The host system will 
isolate and assign resources to all Plug and Play adapters in 
the system at power-up. 

When the driver loads, it must query the resident configura- 
tion manager to obtain the resource information. Refer to 
the Plug and Play Device Driver Kit for information on how 
to locate the Plug and Play Configuration Manager and how 
to obtain the resource information. 

2.2 Legacy ISA Configuration Mode 

Legacy ISA configuration mode is generally used when the 
adapter is placed into an ISA system that does not support 
Plug and Play isolation and resource allocation. In this 
mode, the DP83800 will read the I/O, IRQ and boot ROM 
configuration information from the EEPROM on power-up. 
Drivers will need to use native methods, such as changes to 
the NET.CFG file in the ODI case, to determine the I/O 
base address of the adapter. Once the base address is de- 
termined, the driver can read DP83800 registers to deter- 
mine IRQ and boot ROM information. 
In legacy mode, the DP83800 will still respond to Plug and 
Play isolation sequences. Therefore, if an adapter is left in 
legacy mode and is placed in a Plug and Play system, the 
resources read from EEPROM at power-up will be overwrit- 
ten by the Plug and Play system. With some Plug and Play 
systems, an error message may be displayed indicating that 
the adapter already had resources assigned before Plug 
and Play isolation was performed. 

2.3 EISA Configuration Mode 

The DP83800 can be programmed to respond to access to 
the EISA configuration registers in an EISA system. The 
EISA BIOS can use the registers to program the DP83800 
at power-up using parameters specified in an EISA configu- 
ration file. To enable EISA mode, a DP83800 configuration 
program need only ensure that the EEPROM location con- 
taining the mode configuration byte (word 28h, low byte) be 
set to load only the mode configuration information. The 
host system will assign resources to the adapter at power- 
up. 

Once EISA mode is enabled, changes to the configuration 
can be made through the EISA Configuration Utility (ECU) 
which comes with the EISA machine. 



2.4 Changing Configuration Mode 

In all configuration modes, the DP83800 will respond to Plug 
and Play isolation sequences. Once the adapter has been 
isolated, software can access the PnP Mode Configuration 
Register (PMCR, index OFOh) in the Plug and Play register 
set (see datasheet for complete list of Plug and Play regis- 
ters). From here, the adapter configuration can be changed 
by setting the appropriate bits and issuing a configuration 
"snapshot" by setting the CS bit in the PMCR. When this is 
done, the mode configuration register and the IO/IRQ con- 
figuration registers are stored to the EEPROM. 

3.0 INITIALIZATION 

Several steps need to be performed in order to ready the 
DP83800 for operation. The following section reviews these 
steps in detail. 

3.1 Software Reset 

The first step in initializing the DP83800 is to perform a soft- 
ware reset to the chip. This ensures that all registers are 
initialized to their reset values even if a driver was previously 
run on the adapter. 

In order to perform a software reset, the driver must set bit 
14, the software reset bit in the Command Register, as well 
as bit 3, the modify bit. (The modify bit must be set to alter 
any of the bits in the CR except for the page select bits.) 

3.2 Transmit Modes 

The DP83800 supports three different modes of transmis- 
sion. The driver can select between blind transmit, halt on 
error, and transmit acknowledge mode. 

3.2.1 Blind Transmit 

This is the default transmit mode of the DP83800. In this 
mode, the DP83800 will, upon completion of transmitting 
the first packet in the FIFO, move to the next and immedi- 
ately attempt to transmit it. The DP83800 will continue to do 
this until there are no more packets in the transmit FIFO. It 
will move to the next packet regardless of whether the 
transmission was successful or not. 

This mode is particularly useful in environments where un- 
successful transmissions need not be immediately reported 
to upper layer software. 

To enable blind transmit mode, set bits 5-4 in the Transmit 
Configuration Register (TXCR, variable page 0, offset 16h) 
to 00. 

3.2.2 Halt on Error Transmit 

When halt on error mode is enabled, the DP83800 will con- 
tinue to transmit all of the packets in the transmit FIFO un- 
less there is a fatal transmit error (such as excessive colli- 
sions, out-of-window collisions, etc.). If such an error oc- 
curs, the transmitter stops and the DP83800 will issue a 
transmit error event. The driver can then determine the type 
of error. Once the transmit status is read, the DP83800 will 
continue to transmit the remaining packets in the FIFO. 
This mode allows for faster transmit routines while enabling 
the driver to handle error events as needed. 
To enable halt on error mode, set bits 5-4 of the TXCR to 
01. 



3.2.3 Transmit Acknowledge Mode 

When transmit acknowledge mode is enabled, the DP83800 
transmits packets from the FIFO one at a time. After the 
completion of a packet transmission, the DP83800 issues 
either a successful or erred transmission interrupt. The driv- 
er needs to then read the transmit status for the next trans- 
mission to begin. 

This mode is the slowest transmission mode because of the 
need to acknowledge all packets. It does allow for tracking 
of transmit packets on a per-packet basis. 
To enable transmit acknowledge mode, set bits 5-4 of the 
TXCFttolO. 

3.3 Normal/Early Transmit 

The DP83800 also supports normal and early transmission 
of packets in all of the aforementioned transmit modes. With 
normal and early transmit modes, the driver can be opti- 
mized to provide the best possible throughput in the target 
environment (10 or 100 Mb/s operation, full or half duplex, 
etc.). 

3.3.1 Normal Transmit 

In normal transmit mode, transmission of the packet is not 
started until after the last byte of information is entered into 
the transmit FIFO. At that point, the DP83800 will begin to 
transfer information to the physical media device (PMD). 
To ensure that the DP83800 is set up for normal transmit, 
the driver must set the Transmit Minimum Threshold Regis- 
ter (TMTR, variable page 1, offset 12h) to the maximum 
Ethernet packet size, 1518. With this value, the transmit 
state machine will not initiate transmit until either the maxi- 
mum 1518 bytes are entered into the FIFO or the last byte 
of the packet, if smaller than 1518, is entered. 
It is recommended that normal transmit mode be used when 
the DP83800 is configured for 100 Mb/s operation. At 
100 Mb/s, the wire speed is faster than the maximum 
throughput of the ISA bus. If early transmit mode is used at 
1 00 Mb/s, it is likely that the transmit FIFO will underrun and 
the packet will be lost. Setting the DP83800 to normal trans- 
mit ensures that it will not underrun. 

3.3.2 Early Transmit 

In early transmit mode, transmission of the packet will begin 
when the number of bytes specified in the TMTR are en- 
tered into the transmit FIFO. At this point, transmission will 
begin and continue until either the total number of bytes for 
the packet are transmitted or until the transmit FIFO under- 
pins. 

Because the possibility of an underrun still exists at 
10 Mb/s, the driver must ensure that either the transmit 
data transfer is an atomic operation or that the driver will not 
be interrupted long enough to cause the transmit FIFO to 
underrun. 

When early transmit mode is used, transmission of the 
packet occurs at the same time data is being transferred 
from system memory to the transmit FIFO. This can improve 
overall performance in many instances. 



3.4 Automatic Transmit Packet Padding 

The DP83800 supports automatic transmit padding of pack- 
ets. This is useful when the upper layer protocol passes the 
driver a packet to send where the total byte count is under 
the minimum Ethernet packet size, 64 bytes. In traditional 
Ethernet controllers, the driver needed to pad the packet in 
software before passing it on to the hardware. When auto- 
matic transmit packet padding is enabled, this padding in 
software is not required. The hardware will automatically 
pad the packet as it is being transmitted. 

3.5 Transmit Retries 

In compliance with the specification, an Ethernet controller 
will attempt to transmit a packet up to 16 times. For in- 
stance, if a controller tries to transmit and collides, it will try 
15 more times. If after 16 attempts it is still unsuccessful, 
transmission is usually aborted. 

Many network environments require that the driver attempt 
to re-transmit packets that failed. In the past, software 
needed to keep track of how many times a packet was at- 
tempted. The DP83800 has a register called the Transmit 
Retry Register (TXRR, variable page 0, offset 1Ah) which 
can be used to program the DP83800 to automatically at- 
tempt to transmit these packets again. 
The value programmed into the TXRR specifies the number 
of additional retries in multiples of 16. For example, if it is 
set to 0, the DP83800 will try the normal 1 6 times. If set to 1 , 
it will try the normal 16 times plus an additional 16 times. 

3.6 Receive Modes 

As with transmit, the DP83800 supports multiple modes of 
reception so that the driver can optimize the hardware oper- 
ation for the target environment. The DP83800 supports 
three modes of reception: normal, early and burst. 

3.6.1 Normal Receive 

In normal receive mode, an interrupt for the receive packet 
is not issued to the host until the entire packet is received 
into the receive FIFO. At this point, the driver may move the 
packet from the receive FIFO into system memory. 
To ensure normal receive mode, the driver must set bit 15 of 
the receive threshold register (RTR, variable page 1, offset 
18h) to 0. This disables all receive threshold modes. 

3.6.2 Early Receive 

In early receive mode, the DP83800 is instructed to issue an 
interrupt to the host after a certain number of bytes are 
available in the receive FIFO. At this point, the driver may 
move some of the bytes into system memory. 
Early receive mode is particularly useful in environments 
where data at the beginning of the packet, called lookahead 
data, can be used to determine if any upper-layer protocol 
needs the packet. In this environment it can be determined, 
before the packet is fully received, whether it is needed. If 
not, the DP83800 can be instructed to abort the current 
reception and reclaim the space in the FIFO. If the packet is 
needed by some protocol, the driver can begin to move the 
data before it is entirely received. 



To enable early receive mode, the enable bit in the RTR 
must be set to 1 to enable the receive threshold logic. Then 
bit 14 must be set to to instruct the DP83800 to use early 
thresholds instead of burst thresholds. Lastly, the number of 
bytes necessary before an interrupt is generated should be 
specified in bits 0-11. Typically, this is set to be the same 
as the number of lookahead bytes required by the upper 
layer software. 

When early transmit mode is used, retrieval of the packet 
from the receive FIFO can be done at the same time the 
packet is being received from the wire. Again, overall per- 
formance can be improved. 

3.6.3 Burst Receive 

In burst receive mode, the DP83800 will not issue an inter- 
rupt for every packet that is received. Instead, an interrupt is 
generated when the number of receive packets specified in 
the RTR is reached. 

To enable burst threshold mode, bit 15 of the RTR needs to 
be set to enable the receive threshold logic. Then bit 14 
needs to be set to instruct the DP83800 to use burst receive 
instead of early receive. Lastly, the number of packets 
needs to be specified in bits 1 1 -0. 
Because interrupts are not issued for each packet received, 
it is possible that a number of packets received could be 
less than the threshold set in the RTR. An interrupt would 
not be issued for the packets that are received. For exam- 
ple, let's say that a server normally sends out 3 packets to a 
workstation to query its status. If the threshold was set to 4 
on the workstation, the upper-layer protocol on the worksta- 
tion would not receive the packets to process until one 
more packet is received. The server would timeout waiting 
for the reply and would try to contact the workstation again. 
When it does, more packets would be received and the 
threshold would be met. The upper layer protocols on the 
workstation would then process the first request from the 
server and reply. There would also be another request in the 
FIFO which might confuse the protocols. 
To help ensure the error condition doesn't occur, the 
DP83800 has a receive timeout register (RTOR, variable 
page 0, offset 1Ch). This register can be initialized so that if 
some packets are received but the burst threshold is not 
met in some specified time interval, an interrupt is generat- 
ed anyway. This helps ensure that the workstation or server 
need not wait for some long software timeout to occur. 

Burst receive threshold is typically used in environments 
where there are a large number of small packets and where 
hardware interrupts can cause task switches to occur. In 
these environments, enabling burst receive can greatly de- 
crease the number of time-consuming task switches that 
occur and boost overall system performance (compared to 
using normal or early transmit mode). 



3.7 Interrupt Options 

3.7.1 Interrupt Vector Register 

The DP83800 provides a slightly different interrupt reporting 
mechanism than previous generation Ethernet products. In- 
stead of having an interrupt status register, where each bit 
represents an event, the DP83800 provides an Interrupt 
Vector Register (IVR, fixed page, offset 02h). With the IVR, 
the driver need not read a status register, test each bit, 
perform an action if that bit is set and then clear the bit. 
Instead, the driver need only read from the IVR. It can then 
use the value to determine what to do next. The act of read- 
ing the IVR clears the event from the event queue so the 
driver need not clear any status bits. To service all of the 
events pending, the driver just reads the IVR, services the 
event and reads again until the IVR returns 0. 
For drivers written in assembly language, it is possible to set 
up a jump table in memory to further streamline the servic- 
ing of interrupts. With a jump table, the driver can simply use 
the value returned by the IVR to jump directly to a subrou- 
tine. The following code illustrates how it can be done: 
Jump table initialization for x86 system: 
Jumplable label word 
ISRNoPending dw 

ISRReceiveError dw 

ISRRecelveThreshold dw 

ISRRecelve dw 

ISRTransmitError dw 

ISRTransmit dw 

ISRTxDataSpace dw 

ISRTlmer dw 

ISRSoftware dw 

ISRMIBOver dw 

(The values for all ISR variables need to be initialized to the 
offset of the appropriate service routine.) 
Sample section of driver interrupt service routine to handle 
IVR return values as Indices Into a jump table of service 
routines. RHPA is a macro that returns the value of the 
named register. 

DriverlSRO: 

RHPA ax, HPA_lnt_veotor 

mov bx, ax 

jmp JumpTable[bx] 

3.7.2 Vector Sizes 

The IVR can be programmed to return either 16- or 32-bit 
vector values. This choice is often made depending on what 
environment the driver will be used in. For example, some 
drivers run in DOS real mode environments. Here, only the 
offset needs to be specified for the jump table. Therefore, 
16-bit values should be used. Other drivers run in 386 en- 
hanced mode where 32-bit values would be desirable. 
The IVR size can be set by setting bit of the Mode Config- 
uration Register (MDCR, variable page 0, offset 12h). A 1 
will enable 32-bit IVR values while a enables 16-bit values. 



3.7.3 Interrupt Mask Register 

The Interrupt Mask Register (IMR, variable page 0, offset 
14h) is used to inform the DP83800 what events should 
cause an interrupt and be reported in the IVR. 

Choices for the IMR should be based on environments, 
transmit operating mode, receive operating mode, etc. 

3.8 Node Address Initialization 

The Ethernet node address is stored beginning at location 
24h on the EEPROM device. Most operating systems re- 
quire that the driver configure itself to accept packets ad- 
dressed to its own Ethernet address. To do this, the data 
must be moved from the EEPROM into the CAM. 
Setting up the DP83800 to accept its own Ethernet address 
is a two part process. First the data needs to be moved from 
the EEPROM into a temporary storage location. Once com- 
pleted, the CAM can be programmed with the data read 
from the EEPROM. The sample code below illustrates how 
this might be done: 
int Address [3] ; 
int Count ; 

// First read 3 words from EEPROM 
for (Count = 0; Count < 3; Count ++) 
( 

putReg(EECR, READ | (24h+Count) ) ; 

while (getReg(EECR) & InUse) 

Address [Count] = getReg(EEDR) ; 
! 

// Next write 3 words to CAM. First 
// disable CAM and the write to 
// CAM entry 0. 
putReg(CCR, CAM.DISABLE) ; 
putReg(CCR, WRITE | 0) ; 
for (Count = 0; Count < 3; Count ++) 
{ 

putReg(CDR, Address [Count] ) ; 
! 

// Enable CAM again 
putReg(CCR, CAM.ENABLE) ; 

3.9 Enabling the DP83800 

To complete initialization of the DP83800, the driver must 

enable the transmitter, the receiver and the generation of 

interrupts. 

Enabling of the transmitter and receiver entails setting bits 9 

and 12 (Receive Enable and Transmit Enable respectively) 

in the Command Register. 

Enabling interrupt generation is done by writing a 1 to the 

Interrupt Enable Register (IER, variable page 1, offset 1Eh). 

Once these steps are done, the DP83800 will be ready to 

send and receive packets over the network. 



4.0 RUN-TIME OPERATION 

After initialization and configuration, a driver's main purpose 
is to transmit and receive packets. Although there may be 
instances when a driver may need to reset or reconfigure 
hardware, transmission and reception of packets consti- 
tutes a large majority of the tasks a driver performs during 
run-time. 

4.1 Transmission 

As previously stated, the DP83800 can be configured to op- 
erate in a variety of transmit modes. Depending on the 
mode, transmit operation can vary. 

The most common DP83800 transmit configuration will be 
illustrated below (blind transmit, non-early with automatic 
transmit padding). Following this will be an explanation of 
variations required for different modes. 

4.1.1 Common Transmit Routine 

When the driver gets a packet to be transmitted, it must first 
assemble the transmit command word. The transmit com- 
mand word informs the transmitter how to transmit the next 
packet in the FIFO. Bits 11-0 of the transmit command 
word indicate the total length of the transmit data. This does 
not include the transmit command word, handle word or any 
pad bytes (see below). The other bits in the transmit com- 
mand word are seldom used. Refer to the datasheet for 
further explanation. 

After the transmit command word is assembled, the driver 
sends it to the transmit FIFO by writing to the Transmit Re- 
ceive Data Registers (TRDR0, TRDR1, fixed page, offset 
OCh and OEh). Next the transmit handle word should be 
written. If handles are not being used by the driver, just write 
any 16-bit value. 

Next, the actual packet data should be written to the TRDR 
registers. (If 32-bit OUT instructions are available, they 
should be used as they increase performance.) The driver 
may do 8-, 16- or 32-bit out instructions without need for 
data steering. After all packet data has been moved to the 
transmit FIFO, the driver needs to dword align the FIFO. 
The total number of bytes passed to the FIFO (including the 
command word, handle packet data) must be divisible by 4. 
If it is not aligned, the driver needs to write the appropriate 
number of bytes to the TRDR registers in order to align it. 
Once the FIFO is aligned, transmission will begin and con- 
tinue until the entire packet is sent. Refer to Figure 1 on the 
following page for a diagram of the transmit data structure. 

4.1.2 Halt on Error and Transmit Acknowledge 

Unlike with blind transmit mode, halt on error and transmit 
acknowledge require that the driver read the Transmit 
Status Register (TSR, fixed page, offset 06h) to continue 
transmission after the generation of a transmit interrupt. 



In halt on error mode, the driver need only configure the 
DP83800 to issue interrupts when a fatal transmit error oc- 
curs (FIFO underruns, excessive deferrals, out-of-window 
collisions, etc.). After the transmit error interrupt is generat- 
ed, the driver would read the vector and then read the TSR 
to retrieve the status. Upon reading the TSR, the DP83800 
transmitter will begin transmitting the next packet in the 
FIFO. 

For transmit acknowledge mode, all transmit status words 
must be read, regardless of whether the transmission was 
successful or erred. The driver must program the DP83800 
to interrupt when there is a transmit error or transmit com- 
plete event. Again, upon reading the TSR, the DP83800 will 
begin to transmit the next packet in the FIFO. 

4.1.3 Transmit Free Space Registers 

When a driver needs to send a packet, it can determine if 
there are enough bytes in the transmit FIFO by reading the 
Transmit Free Space Register (TFSR, variable page 1 , off- 
set 16h). Reading the TFSR will return how many bytes are 
currently free in the transmit FIFO. If there are enough for 
the transmit packet, transfer can begin immediately. 
If there are not enough bytes, the driver has two choices: it 
can wait for enough to become available or it can request 
that the DP83800 interrupt it when enough space is avail- 
able. 



To have the DP83800 generate an interrupt when a certain 
amount of free space is available, the driver must program 
the Transmit Free Space Threshold Register (TFTR, vari- 
able page 1, offset 14h) with the desired number of free 
bytes. When the desired number of bytes are available, the 
DP83800 will generate an interrupt and the driver can then 
transmit the packet. 

4.1.4 Miscellaneous Transmit Options 

When automatic transmit padding is disabled, the DP83800 
can be programmed to issue runt packets (packets less 
than 64 total bytes). This is usually undesirable on the part 
of a driver but can be useful to diagnostics software. Many 
times protocols will pass packets where the useful data is 
smaller than 64 bytes. In this case, the protocol assumes 
that the packet will be padded with bytes so that it is of the 
minimum length when transmitted. With automatic transmit 
padding disabled, the driver will need to do this padding 
before it is passed to the transmit FIFO. 
With early transmits, the driver need only ensure that the 
data transfer to the FIFO is not interrupted so long as to 
cause a transmit FIFO underrun. If this happens, it will se- 
verely degrade network performance. 
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FIGURE 1. Transmit Data Structure 



4.2 Reception 

As with transmission, the DP83800 can be configured to 
receive packets in a variety of different manners. The sim- 
plest form of operation is when no threshold mode (early or 
burst) is being used. 

4.2.1 Normal Receive Mode 

Figure 2 shows the data structure for each packet received. 
Following reception, the receive packet data is available 
from the FIFO. Following the receive data are pad bytes (to 
dword align the packet) as well as one reserved word and 
the Rx management status. The Rx management status is 
retrieved when the Receive Packet Advance Register 
(RPAR, fixed page, offset OAh) is read. Also stored for each 
packet is the status/current size in FIFO (this size value will 
decrement as data is moved from the FIFO). 
When a receive complete interrupt is generated by the 
DP83800 the packet data is available through the TRDR 
registers. By simply reading these registers, the data from 
the packet is moved from the receive FIFO to either a regis- 
ter or into system memory, depending on the instructions 
used. 

The receive FIFO can be accessed byte-wide, word-wide or 
dword-wide so the driver does not need to perform any 
byte-steering functions. Because of this, receive fragments 
presented to the driver by the protocols are easy to handle. 



Through the Receive Status Register (RSR, fixed page, off- 
set 08h), the driver has access to statistics such as the 
completion status, whether it was received OK or bad, and 
the number of bytes remaining to be moved. 
Reading of the RPAR will unconditionally move the receive 
FIFO pointers to the next packet. Reading of this register is 
usually performed after the entire packet has been moved 
from the FIFO. However, if interrogation of the lookahead 
data indicates that no protocol needs the packet, the driver 
can simply read the RPAR at any time to advance the FIFO 
to the next packet. 

4.2.2 Early Receive Mode 

With early receive threshold mode, the DP83800 will gener- 
ate interrupts before the entire packet is received in the 
FIFO. The number of bytes required before an interrupt is 
generated is specified in the RTR. 

Typically, the threshold programmed into the RTR matches 
the number of lookahead bytes required by the protocols. 
When these bytes are available, they can be moved from 
the FIFO into system memory for interrogation. If the packet 
is not needed by any protocols, the driver can read the 
RPAR to advance the FIFOs to the next packet. 
If the packet is needed by at least one of the protocols, the 
driver can either wait for blocks of data to be received or 
can wait for the end of packet interrupt to move the data. 
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FIGURE 2. Receive Data Structure 
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If the driver waits for blocks of data to be received, it can 
read the RSR to see how many bytes are available in the 
FIFO. When the desired number of bytes are available, they 
can be moved. Then the driver will wait again until either the 
desired number of bytes are available or until the packet 
reception is complete. This method of reception provides 
high raw throughput but can "hog" processor cycles in a 
multi-threaded operating system. 

Alternatively, the driver can exit the receive routine and wait 
for the end of packet interrupt. This allows for other pro- 
cesses to use the CPU while the reception is completing but 
results in multiple interrupts being generated for each pack- 
et. This could affect system performance in some environ- 
ments. 

4.2.3 Burst Receive Mode 

With burst receive mode, interrupts are not generated for 
each packet received. Instead, the number of packets spec- 
ified in the RTR must be received before a receive complete 
interrupt is generated. 

This is helpful if the DP83800 is to be used in an operating 
system when interrupt hits are costly. (See section 3.6.3 for 
more information on burst receive mode.) 

5.0 OTHER DP83800 FEATURES 

5.1 Full-Duplex Operation 

With standard Ethernet controllers, only one node may 
transmit at a time. If more than one attempts to transmit, 
collisions occur. If a workstation has a packet to transfer but 
another workstation is already doing so, it has to defer. Col- 
lisions and deferrals cause a node to be idle when it could 
otherwise be active. 

With full-duplex operation, a node can begin transmission 
even if it is receiving a packet from another node. This con- 
figuration, when combined with a full-duplex switching hub, 
eliminates the need to collide or defer and boosts total net- 
work performance. 

The DP83800 supports full-duplex at both 10 and 100 Mb/s. 
To configure it to operate in full-duplex, several registers 
need to be accessed. 



First, there needs to be a full-duplex capable PMD attached 
to the DP83800, such as the DP83840. The PMD can be 
interrogated over the Mil to determine if it can support full- 
duplex and if it is configured to operate in that mode. 
If so, the driver then needs to alter some bits in the Transmit 
Configuration Register (TXCR, variable page 0, offset 16h) 
and the Receive Configuration Register (RXCR, variable 
page 0, offset 18h). 

Two bits in the TXCR need to be set. Bit 9 (carrier sense 
ignore) and bit 8 (heartbeat ignore). And a single bit in the 
RXCR, bit 3 (accept transmit packets) needs to be set. 
Once set, the DP83800 will operate in full-duplex mode. 
If the DP83800 needs to be changed back to normal mode 
(for instance, if the PMD is in auto configuration mode and it 
detects a change from full- to half-duplex), all of the bits 
mentioned above need to be cleared. If they are not, the 
DP83800 may cause errors on other nodes. 

5.2 General Purpose Timer 

The DP83800 contains a general purpose timer which can 
be used to generate a single or periodic interrupts. 
The timer is controlled by the Timer Control Register (TCR, 
variable page 3, offset 16h), the Timer Max Count Registers 
(TMRO and TMR1, variable page 3, offsets 18h and 1Ah) 
and the Timer Count Registers (TCRO and TCR1, variable 
page 3, offsets 1Ch and 1Eh). 

The TCR is used to specify whether the timer will run once 
or in continuous mode. If it is run once, it will generate a 
single interrupt. If it is set to continuous mode, it will gener- 
ate periodic interrupts. 

The TMR registers control how high the timer must count 
before issuing an interrupt. The TCRO and TCR1 registers 
give a current reading of the timer value. 
The timer increments once every 800 ns, or the time it takes 
to move a single byte over Ethernet. 
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